Mains signalling systems

ABSTRACT

A control unit for a remote metering system of a mains supply system having plural consumer meter units arranged so messages can pass between the meter units and the control unit includes a router for determining routes to selected meter units via intermediate ones of the meter units. The router for each selected meter includes (1) a route table containing plural possible routes to the selected meter; (2) a route selector for selecting from the table different, previously untried routes; and (3) a route table updater. The untried routes are selected by the selector until one of them is successful, or until all untried routes are found to be unsuccessful. The route table updater generates a fresh route and inserts it into the table by displacing a single route from the table in response to the route selector detecting that all the routes in the table are found to be unsuccessful.

The present invention relates primarily to mains signalling systems,though it is also applicable to other systems having similarcharacteristics. (The term "main" applies primarily to the finalconsumer voltage portions of an electricity supply network, though thesignalling can also extend over the higher voltage distribution parts ofthe network.) Such signalling is termed mains, mainsborne, or power linecarrier (PLC) signalling.

Remote Metering

A major application of mains signalling is remote meter reading,operated by electricity generating and distribution companies(electricity utilities). The term "remote meter reading" refers to whatis normally the major function of such systems, but they may also beconcerned more generally with load and system control. Also, while theywill usually be concerned primarily with electricity meters, gas andother meters can in principle be coupled to the mains for this purpose(preferably through electricity meters).

A typical simple remote meter reading system will have a central stationor local controller (which can conveniently be located at a distributiontransformer) which communicates over the mains with the meters (meterstations) of the various premises (largely household or domestic andsmall commercial) on the mains. Such systems have two major problems:noise and attenuation.

Mains noise arises from loads being switched on and off and the inherentcharacteristics of certain types of loads. The noise problem cangenerally be overcome by a variety of known techniques, such as errordetection and correction techniques, requiring acknowledgement ofreception, and repetition of lost messages. (Some of these techniquesalso deal with problems of message collision.)

Dissipation or attenuation at the preferred signal frequencies issignificant; it is dependent on the particular operating conditions ofthe mains network and varies according for example to the loading of thenetwork. The attenuation will often be irregular; there may for examplebe potential "dead spots", due eg to signal reflections, close to thesignal source while communication to more distant locations is stillreasonably reliable.

A system which largely overcomes these problems has been proposed in ourearlier patent application Ser. No. PCT/GB94/01391, WO 95/01030. In thatsystem, which we will for convenience call the "standard system",substantially all meters have a repeater function. The present system isa broadly a development of or improvement on that system.

The topology of the standard system will normally be branched. That is,the central station will normally be able to communicate directly withseveral meters, each of those will normally be able to communicate withseveral further meters, and so on. (The topology of the communicationsystem is somewhat abstract, and must be distinguished from the physicalor network topology of the mains network which supports thecommunication system. We will normally be concerned with the former, andwill use the term "topology" alone for the former.)

A major feature of the standard system is that the message routing--iethe determination of the routes which messages take through thenetwork--is determined substantially entirely by the central station.This is the only station with any significant knowledge of the topologyof the system, and is also the only station which can initiate amessage.

The central station includes, in each message, a route in the form of ameter list--a list of the meters through which the message is to pass.To read a meter (or otherwise communicate with it), the central stationsends out a message to the meter, which inserts its reading into themessage and sends it back to the centre| station. For present purposes,the route--the meter list--can be taken as remaining unchanged in themessage throughout the message's journey to the destination meter andback again to the central station. (In fact, the standard systempreferably uses slight variations on this.)

Topology Monitoring and Use

The standard system can readily be made adaptive to changes of topology.This is particularly important for mains meter reading. The transmissioncharacteristics of the mains network are liable to change (over timeperiods of the order of minutes to hours). Also, there will beoccasional changes in the number and locations of the meters of thesystem, and the mains network itself may be extended or modified overtime. All these types of changes will change the topology of the system.

The operations of the standard system can be broadly divided into twoclasses. First, there is topology determination; that is, sending SEARCHmessages designed primarily to discover or monitor the topology of thesystem--discovering which units can communicate with which and theappearance or disappearance of meters. (The topology determination modemay be split into two sub-modes, initializing and maintenance.) Second,there is direct messaging; that is, the sending of messages toparticular meters with the primary purpose being to transfer specificinformation between the central station and that meter. (The main use ofdirect messaging will be to read the meter, but it may also be used forother purposes, eg to change a tariff at that meter). Direct messagingrequires knowledge of the topology.

To determine the topology, the central station can send out searchmessages which request identification from meters receiving them.(Various details of this are described in the standard system.) Thecentral station can therefore gradually construct a map of the system.The topology of the system can then be continuously maintained as abackground process, so that changes in it (eg meters gaining or losingcommunication with each other or appearing or disappearing) can betracked.

In the standard system, the map is typically stored in the localcontroller in the form of a topology table, which is essentially a listof all directly communicating pairs of units. When the local controllerwants to send out a message to a meter, it uses the topology table todetermine a path to that meter, eg by starting with the entry for thatunit and backtracking up the table until an entry for the localcontroller is reached.

It may happen that the local controller finds difficulty incommunicating with a meter; it may get no response after severalre-sends, or it may have to re-send for most messages to that meter. Inthat case, it uses the topology table to try to find an alternativeroute to the meter.

Route Optimization

It is desirable for the route to be optimal, mainly to maximize thechances of message reaching its destination (and returning therefrom),but also to minimize message density in the system. This requires analgorithm for determining an optimal route based on the hop qualities,and some form of hop quality evaluation.

There is a well-known algorithm for determining the shortest routethrough a network where the lengths of the connections between the nodesare given. To apply this algorithm, a suitable measure of hop or path"length" or cost must be used. It is convenient to take this asinversely related to the hop quality.

Hop quality can be determined by various techniques. The receiving unitcan measure the signal strength, or a noise signal can be deliberatelyadded to the mains system to discover which hops fail as a result. Theproportion of attempted transmissions over the hop which are successfulcan be determined. Each unit can record all messages which it receives(including those which are directed to other units) and, when itreceives a message for itself, report the results to the localcontroller as part of the return message. Test messages can be sentrepeatedly and the number received monitored (a technique not describedin the standard system).

All these techniques have significant disadvantages. Signal strengthmeasurement requires substantial elaboration of the receiving circuitryin every unit. Using noise signals requires noise signal generators andreliable techniques for controlling them. Measuring the proportion ofattempted transmissions over a hop which are successful yieldsinformation only about those hops which are actually being used, and isalso slow. If all units are required to record all messages which theyreceive, this requires every unit to maintain a list of all units fromwhich it receives messages together with counts of the numbers of thosemessages, and considerably increases the amount of information which hasto be included in messages. Sending repeated test messages greatlyincreases the number of messages being sent, and so reduces the capacityof the system.

These various techniques for measuring hop quality thus all havesignificant disadvantages. We have also realized at the informationwhich they yield is inherently unreliable, as it is generally obtainedfrom statistically small samples, and, as the hop qualities changeunpredictably with time, the information will normally be out of date toan appreciable extent. In addition, frequent recalculation of theoptimum routes from the hop qualities may impose an undue computationalload on the local controller.

A further technique for determining routes through the network isdescribed in Schlumberger, EP 0 395 495 A. In that system, a set of mapsare generated for different times, typically for 2 or 3 periods a dayfor some 2 months, by analysis of network conditions for cyclicrepetitions, and are then selected at the appropriate times thereafter.Each map consists of a list or set of paths for all the meters in thenetwork, so describing the network. Each map is similarly subdividedinto a set of "stacks" each of which is dedicated to a unique time slicefor which the conditions of the network are constant. Each stackcontains lists of different possible paths for each meter, together withdata characterizing the time period and/or network conditions when themap was made.

When a message is to be sent to a particular meter, the appropriate mapis selected, a suitable stack is selected from that map, and the toppath from the path list for that meter is chosen. If the message doesnot reach the meter and return from it (after a suitable number ofretries at suitable intervals), that path is discarded from the top ofthe path list, the remaining paths in the path list are moved up, andthe new top path is chosen. If no path in the path list succeeds inreaching the meter, a global topology determination is made, toinvestigate the topology of the network. Assuming that the meter isstill present and reachable, this will result in a path to it beingfound, and this path will be entered in the path list for that meter.

The global topology determination uses special search-type messages todetermine the topology of the entire network in detail. From thisinformation, a variety of paths to all accessible meters can begenerated. This allows any meter for which the path list is Not full tohave new paths added to its path list. Most of the path lists willtherefore be kept reasonably full.

The size of the path lists is kept small, not greater than 3 paths. Thisis because all the paths in a path list have to be tried before a globaltopology determination is made, and trying several paths (with retries)takes a very considerable time. Since all the paths in a path list aredetermined under substantially similar network conditions, there is agood chance that if one path fails (due, eg, to an unexpected change innetwork conditions), the other paths in the path list will also fail. Soit may be worth trying 1 or 2 alternative paths, but not more, beforeperforming a global network topology determination.

The Present Invention

The general object of the present invention is to provide an improvedrouting technique for the standard system.

Accordingly the present invention provides, in a standard system or thelike, routing means comprising, for each meter:

a single route table which contains a plurality of possible routes tothe meter;

means for selecting among those routes; and

means operative if none of the routes therein enable the meter to bereached for generating a fresh route and inserting it in the table bydisplacing a single route from the table.

The routes are initially generated from a knowledge of the topology, egas determined by means of SEARCH messages. These routes are routes whichare known to work, in the sense that for at least some of the time theyenable communication with the meter to be achieved with reasonablereliability. However, the routes used are not necessarily optimum.Better routes may be possible; but provided that the routes which are inthe route tables work, in the sense just given, those routes will beused even though they may not be optimal. The present system thusoperates on the basis of practical criteria; routes which are found towork are maintained for future use.

The route to a meter may be picked at random from the route table forthat meter. However, it may be desirable to generate merit figures forthe various routes in each route table and to try the routes in order ofmerit. Once a route is found to work, however, that route will generallycontinue to be used until it ceases to work; only then are other routesin the table tried.

If none of the stored routes to a meter are found to work--that is, ifcommunication with a meter is found to be impossible through any of thestored routes for that meter--then the meter is regarded as lost. Inthat situation, the topology of the system needs to be investigated morethoroughly. If the topology is maintained in the form of a list of pairsof stations which can communicate directly with each other, then it maybe possible to determine a new route from that information.Alternatively, SEARCH messages can be used to re-map the system and toattempt to find the lost meter.

It is worth noting that the routes are preferably stored as completeroutes between the local controller and the desired meter. Obviously, itwould be possible to split a route to a remote meter into two parts, afirst part between the local controller and some intermediate meter anda second part between that intermediate meter and the remote meter.However, it would be dangerous to store, for the remote meter, only thesecond part of the route and try to complete the route by concatenatingthat with a route to the intermediate meter Since the topology of thesystem changes from time to time, some of the routes to the"intermediate" meter may in fact pass through the "remote" meter, sosuch concatenation could produce circularity. Although additionalmechanisms could be introduced to avoid that, they would make the systemconsiderably more complicated.

As discussed above, each message includes a meter list which defines itsroute through the system. In the basic form of the standard system, thismeter list is maintained unchanged throughout the life of the message.It is pointed out in the description of the standard system thataddresses can be deleted from the meter list on the return journey ofthe message from the meter back to the local controller. This can ofcourse be done in the present system.

A further variant is also described in the standard system, whereaddresses are deleted one by one from the meter list in the message onits outbound (outward) journey and copied into the meters through whichthe message passes. On the return journey of the message, each meterthough which it passes uses the retained address to forward the messageto the next meter on its return journey to the local controller.

If, in the present system, the local controller may send out a messagebefore the previous message has returned to it (or sufficient time haselapsed for it to be certain that the previous message has been lost),the use of this last variant may cause a minor difficulty. The reason issimilar to the reason why the stored routes are preferably completeroutes between the local controller and the desired meter. If a messageto one meter is sent out and then a message to another meter is sent outbefore the first message has returned, the second message may change thereturn route for the first. However, although in this situation thereturn route may be unnecessarily lengthened, it is unlikely (except invery exceptional circumstances) to become circular. (In the standardsystem, this problem is negligible, because all routes are optimized inthat system.)

SPECIFIC EMBODIMENT

A communication system embodying the invention will now be described, byway of example, with reference to the drawings, in which:

FIG. 1 shows a mains power distribution network and metering system;

FIG. 2 shows the topology of the FIG. 1 system;

FIG. 3 is a block diagram of the central station of the FIG. 1 system;and

FIG. 4 is a more detailed block diagram of parts of FIG. 3.

MAINS NETWORK AND SYSTEM TOPOLOGY

FIG. 1 shows a mains network powered from a substation 10. The networkcomprises a main branch 11 connected to the substation 10 via a line 12,a second branch 13, and a loop branch 14. A central station (localcontroller) LC is connected to the network adjacent to the substation10, and various user consumption meters U1-U11 are connected throughoutthe network as shown. All the meters can also act as relay units. Inpractice, the mains network will typically extend over an area of theorder of 1 km in diameter, and the number of meters will typically be inthe region of 100 to 1000.

FIG. 2 shows a typical topology for this network. The local controllerLC can communicate with meters U1-U3; meter U1 can communicate onwardswith meters U4 and U5; and so on. This tree corresponds roughly with thephysical closeness of the meters in the physical network of FIG. 1, butthe correspondence will in general not be exact. In practice, themaximum path length, ie the maximum number of hops required for thelocal controller to reach a meter, will typically be 3 or 4. In somesystems, however, the number of hops required to reach the most remotemeter may be considerably greater than that.

Message Format and Transmission

To read the contents of a meter or to control it, the local controllersends a message to the meter, and the meter returns the message suitablymodified. The message return occurs for all messages, acting as anacknowledgement so that the local controller knows that the message hasbeen received. (If no message return occurs, the local controller doesnot know whether the message was lost on the outward or return journeys,and automatically re-sends the message). The message format comprisesthree main fields: a command field, a route field, and a data field.

The route field defines the path which the message is to take throughthe system from the local controller to the meter and back again, andcomprises a control subfield and a meter list--a sequence of meteraddresses defining that path. The control subfield includes a directionindicator (eg O for outbound (outward) and 1 for inbound (inward,return)), a meter list length, and a marker which is effectively movedalong the meter list as the message moves through the system to indicatethe next meter which is to receive it as the message passes through thesystem.

Thus for a message being sent to meter U7, for example, the data pathfield will initially consist of a control subfield O-3-2 and a meterlist LC-U3-U7. In the control subfield, the first character, O,indicates that the message is an outward one, the second is the labelsequence length, and the third is the pointer. The following tablesummarizes the progress of the message:

1: LC→U3 U7

2: LC U3→U7

3: LC U3←U7

4: LC←U3 U7

This shows the four stages in the outward and return journeys of themessage, with an arrow instead of the control subfield to indicate boththe active address and the direction of travel. At each stage, themessage will normally be received by several stations, but only thestation which matches the active address accepts and (except for thelocal controller) retransmits it.

FIG. 3 is a block diagram of the local controller LC. A modem 21'couples the mains line 12 to a message assembly and disassembly unit22'. This has sections for the different fields of the message format: acommand section 22A' the command field, a control subsection 22B' forthe control subfield, a route subsection 22C' for the meter listsubfield, and a data section 22D' for the data field.

The local controller is controlled by a (main) control unit 35. The datasection 22D' of the message unit 22' is coupled to a data memory 28'which is coupled to and controlled by the control unit 35. The controlunit 35 is also coupled directly to the message unit 22', andspecifically to the route subsection 22C'. The control unit is alsocoupled to a topology control unit 40, which is in turn coupled to atopology list memory 36. (In the standard system, the topology memory 36is shown as being coupled directly to the control unit 35, but forpresent purposes it is more convenient to regard it as coupled to thetopology control unit 40 as shown here. In effect, we have here simplyseparated out the topology control functions of the control unit 35 andlabelled them as the topology control unit 40.)

In the standard system, the local controller generates various searchmessages, under the control of the topology control unit 40, to discoverthe topology of the system, in the form of a list of pairs of unitswhich can communicate with each other with reasonable reliability. Thislist is stored in the topology memory 36. The topology control unit 40also causes this list to be maintained and updated as a backgroundprocess.

In operation, the main control unit 35 generates messages to be sent outto the various meters and processes the messages on their return. Togenerate a message, all the various sections and subsections of themessage unit 22' have to be filled, including in particular the routesubsection 22C'. In the standard system, the meter lists for routingcontrol are generated from the list in the topology memory 36. (In thestandard system, the control unit 28' is described as performing thistask, but it is more convenient to regard this task as being performedby the topology control unit 40.) The meter list may be generated by asimple sequential look-up from the topology memory entries, or by a moreelaborate process such as the routing algorithm mentioned above.

The Present System

In the present system, there is a set of route tables stored in a routetables memory 45, and the main control unit 35 obtains the desiredroutes from this memory. This memory contains a separate route table foreach meter U1, U2, U3, etc. Each route table consists of a list ofpossible routes by which the local controller can probably reach themeter. FIG. 4 shows the route table 45-1 for meter U9. As shown, thistable consists of a set of route storage locations 46-1, 46-2, etc eachof which contains a possible route for reaching meter U9.

The routes in a route table are routes which have been found in practiceto be effective for reaching the meter. These routes may be generated inany of the ways described in the standard system from the basic topologylist 36 and any other available information such as hop qualityinformation.

When the local controller wants to communicate with a meter, the controlunit 35 selects the route table for that meter. A route selector 47(FIG. 4) then selects a route for that meter--ie it selects a locationin that route table. In principle, the route selector can select a routeat random from the route table, but it is preferable for the routeselection to be made according to some form of algorithm, as discussedbelow.

The route selector 47 maintains a pointer to the selected location (iethe selected route), so that the same route is selected for futurecommunications with that meter. There is a separate pointer for eachmeter, ie for each route table. The pointer can be regarded as beingstored in a pointer location in the table, as indicated at 46-0.

There is also a failure counter 48 which counts the number of attemptswhich have to be made to communicate with the meter before the localcontroller successfully receives a message back from the meter. Inprinciple, there can be a single failure counter for all meters.However, it may be desirable for the local controller to try tocommunicate with a second meter while still awaiting the return of amessage from the first. In this case, it is necessary to maintainseparate failure counters for the different meters, and each failurecount can then be regarded as being stored in a failure count locationin the appropriate route table along with the pointers.

If a message is not received back within a suitable time, it is regardedas being lost. The count in the failure counter is incremented by 1, andthe message is re-sent. If the count in the failure counter becomes toolarge, then the route is regarded as no longer valid. The route selector47 thereupon selects another route from the route table.

Associated with the failure counter 48 there is a route failure counter49. This counts the number of routes which are found to be invalid. Ifall routes in the route table are found to be invalid, ie all routes inthe table have been tried, each for the appropriate number of times, andcommunication with the meter has still failed to be achieved, then themeter is regarded as lost. Obviously, both counters 48 and 49 are resetas soon as a message is received back from the meter.

If the meter is lost, this is signalled to the topology control unit 40,for that unit to attempt to generate a new route to the meter or toinitiate a search for the meter by means of SEARCH messages. Once a newroute has been generated, it is added to the route table 45 for thatmeter (displacing an existing route if the table is full), and used bythe control unit 35 to attempt to communicate with the meter.

The routes in the route table 45 can be arranged in arbitrary order (egthe order in which they are generated). The route selector 47 can thenselect them in cyclic order, or sequentially starting from the top ofthe list each time a route which has been successful becomes invalid.However, it is obviously desirable to minimize the number of attemptsneeded to establish communication with a meter, and it is also generallydesirable to minimize the number of hops per message. A better techniquefor selecting routes from the route table is therefore desirable. Thisinvolves arranging the routes in an order of merit. (This can be thoughtof as involving a re-ordering of the routes in the route table, but inpractice it can be achieved by a suitable pointer chaining mechanism.)

With the routes arranged in an order of merit, the route selector 47preferably selects them sequentially, starting from the top of the listeach time a route which has been successful becomes invalid. The chosenroute is then the best route at the time when it is chosen. However, astime goes on so the system conditions may change, and some better routemay become available even though the current route remains successful.It may therefore also be desirable for the route selector to try routesof lower merit occasionally even though the current route remains valid.This can be triggered by a timer or a message counter.

For the routes to be arranged in order of merit, each route in the listmust have a merit figure. A simple form of merit figure is to take thenumber of hops which a route involves; the fewer hops, the better themerit figure. The choice between routes with the same number of hops canbe arbitrary, depending eg on which order they happened to be generatedin. This is simple and effective, though for distant meters, routes withfew hops will be preferred even though those hops may be long andtherefore somewhat less reliable than the hops of some routes with morehops.

Alternatively, the locations in the memory 45 may have extensions 51 forstoring explicit merit figures. It is desirable for the algorithm formaintaining the merit figures to be simple. A convenient algorithm isfor a success counter 50 to count the number of successfulcommunications with the meter using the currently selected route. Whenthe route finally becomes invalid (as indicated by the count in thefailure counter 48 reaching its limit), the merit figure for that routeis read out from the appropriate location 51 in the table 45, divided bya constant k in a divider 52, added to the success count from counter 50in an adder 53, and returned to the merit figure location 51 for thatroute. The success counter is also reset, to start counting successesfor the next route selected by the route selector 47.

There is a separate success counter for each meter, i.e. for each routetable; the success count can be regarded as being stored in a successcount location in the table, along with the pointers.

The constant k is chosen to be slightly smaller than 1, and canconveniently be of the form (1-2^(-n)), eg 7/8; the division can then beperformed by a shift and subtract operation. The effect of thisalgorithm is to form a kind of running average of the success counts forthe times when the route has been selected, with the success counts forrecent selections of the route having greater weights than for oldselections. The resulting merit figure follows recent success counts,but is not excessively disturbed if, for example, an isolated noiseburst makes a normally successful route temporarily invalid. To avoidthe merit figure becoming excessively large, an upper limit is set forit.

If a route often requires several attempts, it will usually not be thatlong before the number of attempts exceeds the limit and becomesinvalid. The merit figure for each route thus effectively takes accountof the number of attempts which fail for that route (without exceedingthe limit set by the failure counter 48).

If desired, the merit figure for each route may be adjusted inaccordance with the length of the route. However, this also increasesthe complexity of the system. It will also be realized that since no hopis likely to be completely reliable, the merit figure will automaticallybe smaller for unnecessarily long routes.

Other more elaborate techniques can also be used. For example, thesystem conditions may vary in a roughly regular manner over the courseof a day or a week, so that certain routes may be satisfactory, atcertain times. The route selector can then be arranged to select routesin a sequence dependent on the time of day. However, all suchelaborations increase the complexity of the system.

We claim:
 1. A control unit for a remote metering system of a mainssupply system having plural consumer meter units, the control and meterunits being arranged so messages can pass between the meter units andthe control unit, the control unit comprising a router for determiningroutes to selected meter units via intermediate ones of said meterunits, the router comprising for each selected meter:a route tablecontaining plural possible routes to the selected meter; a routeselector for selecting from the table different, previously untriedroutes, the untried routes being selected by the selector until one ofthem is successful, or until all untried routes are found to beunsuccessful; and a route table updater for generating a fresh route andinserting it into the table by displacing a single route previously inthe table from the table in response to the route selector detectingthat all the routes in the table are found to be unsuccessful.
 2. Thecontrol unit of claim 1 wherein the plural possible routes are stored ina single route table.
 3. The control unit of claim 1, wherein the routerincludes locations for storing, for each route, a figure of merit forthat route.
 4. The control unit of claim 3, further including anadjuster for adjusting the figure of merit for a route in dependence onthe quality of that route.
 5. The control unit of claim 3 wherein thelength of a route is taken as its figure of merit.
 6. The control unitof claim 1, wherein the route selector selects routes in cyclicsequence.
 7. The control unit of claim 6 further including a failurecounter for counting the number of successive failures of successiveroutes.
 8. The control unit of claim 1 further including a failurecounter for counting the number of successive failures of a route. 9.The control unit of claim 1 wherein the route selector selects routes independence on at least one of the time and conditions in the mainssystem.
 10. In combination, a mains supply system, a remote meteringsystem for the mains supply system including plural consumer meter unitsand a control unit for the meter units, the control and meter unitsbeing arranged so messages can pass between the meter units and thecontrol unit, the control unit comprising a router for determiningroutes to selected meter units via intermediate ones of said meterunits, the router comprising for each selected meter:a route tablecontaining plural possible routes to the selected meter; a routeselector for selecting from the table different, previously untriedroutes, the untried routes being selected by the selector until one ofthem is successful, or until all untried routes are found to beunsuccessful; a route table updater for generating a fresh route andinserting it into the table by displacing a single route previously inthe table from the table in response to the route selector detectingthat all the routes in the table are found to be unsuccessful.
 11. Thecombination of claim 10 wherein the plural possible routes are stored ina single route table.
 12. The combination of claim 10, wherein therouter includes locations for storing, for each route, a figure of meritfor that route.
 13. The combination of claim 12, further including anadjuster for adjusting the figure of merit for a route in dependence onthe quality of that route.
 14. The combination of claim 12 wherein thelength of a route is taken as its figure of merit.
 15. The combinationof claim 10, wherein the route selector selects routes in cyclicsequence.
 16. The combination of claim 15 further including a failurecounter for counting the number of successive failures of successiveroutes.
 17. The combination of claim 10 further including a failurecounter for counting the number of successive failures of a route. 18.The combination of claim 10 wherein the route selector selects routes independence on at least one of the time and conditions in the mainssystem.